[レポート]YAPC::Asia TOKYO 2015 Day 2(インフラ系) #yapcasia

[レポート]YAPC::Asia TOKYO 2015 Day 2(インフラ系) #yapcasia

Clock Icon2015.08.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

YAPC::Asia Tokyo 2015 Day 2に参加してきました。私が聴講したトークの中から、インフラよりのものを中心にごご紹介します。

ISUCONの勝ち方 by Masahiro Nagano

abstract http://yapcasia.org/2015/talk/show/86ebd212-fab3-11e4-8f5a-8ab37d574c3a

3行でまとめると

  1. ISUCON は実サービスを意識したパフォーマンス厨向けコンテスト
  2. 各システムの動作原理を具体的に理解すること
  3. コンテストなので競技ルールに則ること

ISUCON について

ISUCON はWebアプリの高速化コンテストです。 アプリのコードをいじる事ができないチューニングコンテストへのアンチテーゼでもあり、 レギュレーション範囲内であれば、どんなチューニングもOKです。 ベンチマークのためのベンチマークではなく、実際にありそうな Web アプリに対して、サービスの特性を考慮したベンチマーク方法が採用されています。

裏の狙い

バックグラウンドや言語、ロールに関係なく、オープンに競いあうことで、エンジニアと業界の技術力の向上に寄与。

Web アプリのパフォーマンスはなぜ重要か

Webページのレスポンスが遅いと、ユーザーにサービスをしてもらいにくい。 サーバがチューニングされると、より低いサーバスペック、サーバ台数でサービス運営できることになり、ランニングコストが下がる。特に大規模インフラではインパクトが大きい。

ISUCONの勝ち方

  • ルール・ベンチマークの計算方法は最初に目を通すこと
  • 2−3人が7時間の短期決戦でチューニングするため、コミュニケーションコストが下がるように、メンバー、コミュニケーションツールを選ぶ
  • 言語・ミドルウェア・OSノプロファイルツールに慣れ親しむ
  • ネットワーク通信は遅い。できるだけ通信が発生しないようにする
  • B+treeの気持ちになって、データベースのデータ走査を思い描くこと
  • CPUの気持ちになって、プロセス・スレッドのコンテキストスイッチのオーバーヘッドを思い描くこと

など

関連サイト

我々はどのように冗長化を失敗したのか Kenji Naito

abstract http://yapcasia.org/2015/talk/show/f2816038-10ec-11e5-89bf-d7f07d574c3a

3行でまとめると

  1. 冗長化は自前やることではない。外部サービスを利用すべし
  2. MySQL(mysqlfailover)とRedis(Redis Sentinel)の冗長化を目指したが、不具合を解決しきれず、各種シナリオでの検証が不十分のため本番投入できず
  3. 疑問点をなくすために完全に検証をやりきる

Master/Slave 構成での Master の切り替え

Consul を DNS サーバとして利用 dnqmasq を使って、.consul ドメインは Consul のIP:PORT で名前を引くようにする Master 障害時には Consul の IP アドレスを書き換える

QA から

Master の IP をインスタンス間で付け替える Floating IP パターンのほうが素直だと思う(QAから) 用途に適しており、Packerなど他のプロダクトからの Hashicorp への信頼から Consul を採用した

関連サイト

ソーシャルゲームにおける AWS 移行事例 by tkuchiki

abstract http://yapcasia.org/2015/talk/show/32a684e8-fd21-11e4-94eb-bdc07d574c3a

3行でまとめると

  1. AWS マネージドサービスを活用して運用負荷を軽減
  2. オンプレからAWSの移行により、リソースのコントロールが楽になった
  3. データ移行を伴うインフラ移設では、予行演習を何度もやること

オンプレ→AWS移設について

10数台程度のシステムでは1ヶ月、実稼働2−3人のリソースでAWS移設できた。 ロードバランサー(HAProxy)、MySQL, Redis はマネージドサービスに移行して運用負荷を削減 データ移行時には RDS を Single AZににすると、マルチAZに比べて書き込み負荷が減るので、データ移行時間を削減できる 新本番環境でデータ移行試験を実施 インフラ移設は構成を見直し、システム改善するいい機会

DB の冗長化について

MySQL/Redis

  • AWS 丸投げ
  • フェイルオーバーは3-5分で完了するので、ユーザーに我慢してもらう

yrmcds

  • AWS 移設のタイミングで Kyoto Tycoon からサイボウズ製の Memcached 互換な yrmcds に変更
  • Consul の分散ロックを使って Master を決定
  • Master が落ちた時は、新規にロックを取得した Slave に VIP を付け替え、Master 昇格させる
  • 本番導入後のトラブルにより、 Consul を使うのをやめ、ベストエフォードで手動切替

関連サイト

データ分析基盤を支える技術 Masahiro Nakagawa

abstract http://yapcasia.org/2015/talk/show/dd8ce20e-fad2-11e4-b6e7-8ab37d574c3a

3行でまとめると

  1. 自前運用せず、外部サービス(AWS でいえばRedshift, EMR など)を活用して分析基盤を構築すべし
  2. BI ツール・ダッシュボードも自前開発せず、ベンダーから購入すべし
  3. SQL は重要

データ分析基盤について

分析するには何をするにもデータを貯めこむのが必要。データがなければ何も始まらない。 今風にデータ分析基板を構築すると、

などたくさんの技術運用があり、(とりわけ Hadoop の)運用負荷がものすごく高い。

OSSを中心に組み合わせたデータ分析基板

※画像は発表スライドから

データ解析したいのであって、インフラ運用したいわけではないではないので、外部サービスを利用すべし。

Amazon でいえば、Redshift, Kinesis, EMR, S3 などを活用して、分析基盤を構築できる。

AWSを中心に組み合わせたデータ分析基板

※画像は発表スライドから

Google や Microsoft Azure にも類似のサービスがある。

BIツール・ダッシュボード

データ管理・可視化・分析など考えるべき要素がたくさんあるため、自前で一から作らないほうが良い。 Tableau のような優れた可視化・分析ツールがあるので、お金を払っていろんなベンダーに頼ったほうが良い。

関連サイト

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.